Unless otherwise indicated herein, the approaches described in this section are not admitted to be prior art by inclusion in this section.
A vendor may provide a product that allows a customer to restrict access to executables (e.g., programs) per user. For example, a user may enter his/her working time into a human resource (HR) program, and see his/her payroll in a payroll application, but the user is restricted from seeing the payroll for other users. Also, a user may record time on projects the user is assigned to, but not other projects. The vendor may ship the product with a large number of roles and authorizations. The roles may be assigned to users. For example, a role may be a project manager. Also, each role may include a number of authorizations. These authorizations are used to determine whether or not the user can access executables and which data. For example, a project manager may be authorized to access more data than a person that is working on the project being managed by the project manager.
Typically, the customer receives the roles from the vendor and then copies the roles into the customer's name space. Then, the customer can assign the roles to users. Due to the large amount of roles and authorizations included in the vendor product, it may be complicated for the customer to manage the number of roles and authorizations especially when updates to the roles and authorizations are received from the customer at a later time. For example, some users may include many roles, which include an even larger number of authorizations. This may be hard for an administrator to keep track of. Further, a user, such as a project lead, is typically assigned many roles and not just one role, and those many roles include many authorizations that may not be used by the user. This may give the user authorizations that the company may not want to give to the user.